Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Aviso
titleObservações
  1. Para vendas NFCE com desconto NO TOTAL, a integração considerará sempre como desconto NO ITEM, pois o xml no NFCE-Sefaz sempre considera o desconto no item , independente da forma como foi praticado o desconto no PDV. Para evitar impactos de base de cálculos nos impostos , não será realizada nenhuma conversão de valores.
  2. Campo: D2_CSOSN Não é gravado em uma venda pelo venda assistida, porem via integração é, após analise identificamos que o campo é utilizado somente no NFESEFAZ para envio de uma mensagem nas observações da nota, portanto não foi encontrado nenhum impacto no processo de venda.
  3. Os campos TOTFED/TOTEST/TOTMUN da SL1/SL2 não são gravados na venda integrada do PDVSync por não existirem estes campos nas tabelas da base do PDV, e conforme verificado e alinhado com o PO, os campos no PROTHEUS não geram impacto nos livros fiscais. 
  4. Na venda PDVOMNI os cálculos para informativo da lei da transparência são arredondados, já no Protheus os campos TOTFED/TOTEST/TOTMUN não são arredondados.
  5. Campos L2_DESC\D2_DESC de percentual de desconto não são gravados na integração, porem não interferem nos cálculos, porque os valores de desconto estão OK.
  6. Campo L2_PICM não grava no registro do PROTHEUS, porem no registro da integração grava o que esta correto. SF2, SD2 e para frente grava corretamente.
  7. Quando algum item estiver com o CST 60 ou CSOSN 500 em venda com SAT, ficou definido que os campos abaixo terão seu conteúdo calculado diretamente pela MATXFIS, porque pelo XML SEFAZ não é possível chegar nestes valores.
    1. F2_VALICM, F2_ICMSRET, F2_BRICMS
    2. D2_VALICM, D2_ICMSRET, D2_BRICMS, D2_ALIQSOL
    3. F3_VALICM, F3_ICMSRET, F3_BASERET
    4. FT_VALICM, FT_ICMSRET, FT_BASERET
    5. Campos da SL1 e SL2 não serão atualizados.
  8. Para retenção de ICMS com base reduzida, alguns cálculos são necessários arredondamento para o valor do ICMS ficar correto nos livros fiscais, com isso os parâmetros abaixo são necessários:
    1. https://centraldeatendimento.totvs.com/hc/pt-br/articles/360023920652-CROSS-Segmentos-TOTVS-Backoffice-Linha-Protheus-FIS-Arredondamento-de-Impostos
    2. https://centraldeatendimento.totvs.com/hc/pt-br/articles/235534847-Como-evitar-diferen%C3%A7a-de-centavos-no-arredondamento-dos-ambientes-SIGALOJA-e-SIGAFRT-
    3. Encontrado diferença de 0,01 centavo na base de calculo de ICMS reduzido entre PDVOMNI e Protheus. Estamos acatando o valor enviado via xml pelo PDVOMNI.
  9. Para PIS COFINS Via Apuração a configuração do cliente deve ser, A1_RECPIS = "N" e A1_RECCOFI = "N". Com isso serão gravados os campos abaixo na venda:
    1. L2_VALPS2, L2_BASEPS2, L2_ALIQPS2, L2_VALCF2, L2_BASECF2, L2_ALIQCF2
  10. Para PIS Cofins via Retenção a configuração do cliente deve ser A1_RECPIS = "S" e A1_RECCOFI = "S". Com isso serão gravados os campos abaixo na venda:
    1. L2_VALPIS, L2_BASEPIS, L2_ALIQPIS, L2_ALIQCOF, L2_BASECOF, L2_VALCOFI
  11. Os acréscimos contidos na venda integrada serão informados no campo L2_DESPESA, pois a venda do PDVOmni realiza os acréscimos das vendas destacando os valores de despesa na tag vOutro do XML.
    1. Para soma de acréscimo/despesa na base de calculo acionar o parâmetro MV_FRTBASE e campos na tes usada no produto, conforme documentação do parâmetro: IMP0030_Despesas_acessórias_( seguro_e_frete)_para_base_dos_impostos_PIS/COFINS_(Apuração)
  12. Em caso de reintegração de venda cancelada no Protheus deverá ter intervenção manual, deletando a Tabela (MEP- em caso de venda parcelada) e as tabelas SFT , SF3 para ajuste de livro fiscal.
  13. PDV OMNI não atende ICMS90, mais detalhes:
    Jira
    serverJIRA
    serverId0c783de1-186e-383b-975c-a1acd7d76cb5
    keyDVARLOJ1-7453
  14. MV_PSHMOV - Parâmetro que habilita a geração de NCC movimentação financeira. = .T. - Quando a NCC é online via API, como por exemplo é utilizado no PdvSync o conteúdo do parâmetro deverá ser igual a .F. → Falso. 
  15. A gravação do campo L4_NSUTEF não terá nenhum tipo de tratamento, será exatamente o conteúdo do campo NsuHost (Nsu do host autorizador) retornado pelo PDVOmni. Atualmente o PDVOmni não tem a informação do TEF de Nsu do SiTef e vimos que esta informação só é utilizada pelo Sitef.
    1. Para qualquer alteração no conteudo do campo deve-se fazer via customização utilizando os pontos de entrada no MVC do fonte RetailSales.
  16. Para manter o legado (compatibilidade com TotvsPDV), os campos do cabeçalho: L1_VENDTEF, L1_DATATEF, L1_HORATEF, L1_DOCTEF, L1_AUTORIZ, L1_INSTITU, L1_NSUTEF, L1_TIPCART e L1_PARCTEF, serão salvos com os dados do ultimo pagamento de alguma destas formas de pagamento CC|CD|PD|PX.
  17. Para vendas onde foi utilizado como pagamento NCC (Crédito de Devolução), em caso de cancelamento, o valor na NCC/Crédito não é estornado, deve ser realizado processo manual no ERP para estorno da baixa ou geração de novo crédito. 


Cadastrando o Processo de VENDA

Para integrarmos o processo VENDA com o PdvSync primeiramente é necessário acessar o cadastro do Processo para verificar se o processo VENDA foi criado automaticamente no Protheus.

...

Tabela: SL1

Chave: L1_FILIAL+L1_NUM

Vinculando o Processo de VENDA ao Assinante PdvSync

1- No módulo 12 (Controle de Lojas), acesse Atualizações/ RMI/ Cadastros/ Assinantes.

...